A transport network (TN) is used to carry data signals between a Radio Base Station (RBS), such as a NodeB or an eNodeB in 3G Long-Term Evolution (LTE) networks, and a Serving gateway (S-GW) or Packet Data Network gateway (PDN-GW). A TN may be operated by a mobile network operator or by a third party transport provider. In the latter case there would be a Service Level Agreement, SLA, between the mobile and transport operators. With the rapid growth of digital data telecommunications following the introduction of 3G and 4G technology, TNs may frequently act as bottlenecks in the overall data transport process. Thus, various systems and methods have been proposed for improving or prioritizing the way that data packets are transported by the bearers.
Service differentiation in the Radio Access Network (RAN) is one supplementary means for more efficiently handling high volumes of traffic. As a simple example, using service differentiation a higher bandwidth share can be provided for a premium service, and in this way the overall system performance can be improved. As another example, a heavy service such as p2p (peer-to-peer) traffic, can be down-prioritized. Implementing such service differentiation methods requires integration into the Quality of Service (QoS) concept of LTE and Universal Mobile Telecommunications System (UMTS) technology. Details of the QoS concept for LTE can be found in the 3rd Generation Project Partnership (3GPP) Technical Specification TS 23.410, while for UMTS the QoS concept and architecture can be found in TS 23.107. The main idea of this concept is that services with different requirements use different bearers. This is illustrated in FIG. 1, which shows traffic flows between a User Equipment (UE) 10 and a PDN-GW 18 via an eNodeB 12, a TN 14, and a S-GW 16. FIG. 1 also shows the up-link (UL) traffic between the Application/Service layer 19 and the UE 10, as well as the downlink (DL) traffic between the Application/Service layer 19 and the PDN-GW 18.
When the UE 10 attaches to the network a default bearer is established (typically a best-effort service). However, if the UE invokes services having different QoS parameters, then dedicated bearers are established for each service, as shown by the parallel traffic flows in FIG. 1.
In International patent application No. PCT/EP2011/068023, the present inventors have described a mechanism for a per-bearer level service differentiation, that makes the bandwidth sharing among bearers more RAN-controlled. This is described further below in relation to FIG. 1. The mechanism employs the concept of “colour” profiling similar to that defined by the Metro Ethernet Forum (MEF) in “MEF 23, Carrier Ethernet Class of Service—Phase 1”. As a way of indicating which service frames (or data packets) are deemed to be within or outside of the Service Level Agreement (SLA), colours are assigned to the data packets according to the bandwidth profile. Note that there is no technical significance to the colour itself, which is just used as a convenient way of describing and/or labeling the data packets. Levels of compliance are green when fully compliant, yellow when sufficient compliance for transmission but without performance objectives and red or discarded when not compliant with either. The data packets of a bearer are checked against the compliance requirements by a bandwidth profiler, for example a two-rate, three-color marker. This validation process can be used between two parties (e.g. between two operators) and can be part of the SLA. In general, in the SLA different requirements are set for green packets and yellow packets. The green packets are “more important” than the yellow packets. To reflect this difference between two types of packets, at a bottleneck point such as on entry to a TN, a colour aware active queue management discards yellow packets in preference to green packets when there is congestion (i.e. insufficient bandwidth available in the TN to transport all data packets). Thus, for each RB a predefined profiling rate (i.e. green rate) is assigned based on the Quality QoS Class Identifier (QCI) of the RB. This mechanism allows bandwidth guarantees to be provided for the RBs, at least to a certain degree.
FIG. 2 shows a schematic illustration of a TN employing bandwidth profiling for each of two bearers. The same entities shown in FIG. 2 have the same reference numerals. The example is shown of an LTE system with two bearers 202, 204 each carrying data packets between the PDN-GW 18 and eNodeB 12 via S-GW 16 and through TN 14. The Bearers 202, 204 are designated S5/S8 bearers 202a, 204a between the PDN-GW 18 and the S-GW 16, S1 bearers 202b, 204b from the S-GW 16 over the TN 14, and radio bearers 202c, 204c beyond the eNodeB 12. Each Bearer is assigned a bandwidth profiler—profiler 214 for bearer 202 and profiler 216 for bearer 204. Each of the bearers has an assigned QCI and an associated predefined ‘green’ rate (CIR). This example is of a single rate, two-colour profiler, in which data packets that are conformant with the green rate are designated as green packets 218, and packets that are not conformant are designated as yellow packets 220. For example, assume that the ‘green rate’ is 5 Mbps for a Bearer and the bitrate of this Bearer is about 7.5 Mbps. In this case, approximately ⅓ of the packets of the Bearer will be assigned to ‘yellow’.
The TN bottleneck active queue management can then use the colour information marked in the data packets when choosing which packets to drop when there is insufficient bandwidth (congestion). The first packets to be dropped will be the ‘yellow’ packets 220.
In the example described, when the profiler 214, 216 assigns a Packet either ‘green’ or ‘yellow’, this means that the packet is marked with the conformance information in such a way it can be used at the TN bottleneck buffer(s). For example the Drop Eligibility (DEI) bit of the packet's Ethernet frame, or the Differentiated Services Control Point (DSCP) field in the IP header could be used to indicate if a packet has been assigned ‘green’ or ‘yellow’.
The colouring concept is used in PCT/EP2011/068023 for improving per-service or per-bearer fairness at a bottleneck. The colouring concept is used in a different way for a different purpose and at a different location (i.e. it is done in the RAN node instead of in the Mobile Back Haul, MBH, node). In this case when a bearer has yellow packets that means that it has a higher bandwidth than the desired value (but gains from this higher bandwidth when the data packets are transported through the bottleneck), so the drop of these yellow packets probably does not have a serious negative impact on the service performance. Consequently, in this case, the use of green and yellow packets improves the fairness of resource sharing among user services.
Even if service differentiation is not required (e.g. there is equal sharing) very unfair situations can still arise. In a RAN TN a single aggressive user (i.e. bearer) using many parallel flows can throttle the TN, as shown in FIG. 3. The left-hand illustration shows an aggressive user with four parallel Transport Control Protocol (TCP) flows leaving very little capacity available for other (normal) users. The right-hand illustration in FIG. 3 is shown for comparison only for the much fairer situation that arises in an Asymmetric Digital Subscriber Line (ADSL), in which both an aggressive user (4 TCP flows) and a normal user take up the same amount of TN capacity.
The unfairness depicted in FIG. 3 can be solved by applying flow control or traffic profilers as described above. However, these solutions cannot overcome the fair usage problem within a single bearer. There are many networks in use today that do not support use of network initiated secondary bearers, particularly those using High Speed Packet Access (HSPA) equipment. In-bearer unfairness is a very similar problem to that illustrated in FIG. 3—i.e. an aggressive service using many parallel flows can throttle other services. In addition, even where all users are well-behaved and there is no aggressive throttling of a TN, existing methods do not provide for any differentiation of resource sharing, such that lower priority services suffer more degradation regardless of which user they belong to.
The current 3GPP-defined QoS-based solutions also share a common problem with the 3GPP defined QoS architecture, which is the need for extensive signaling between nodes and the added complexity of an Rx interface. The QoS-based solution is difficult for third party service providers to implement and requires extra nodes and a heavy signaling overhead making it expensive for the operators in terms of performance and maintenance.